1. Field of the Invention
The present invention relates to a debugger for a microprocessor having a cache memory therein, and more specifically to a debugger which can break at an arbitrary address.
2. Description of Related Art
Recently, microprocessors increasingly have an internal cache memory for attaining a high speed memory access. Accordingly, the performance of microprocessors has become high, but, the process of debugging the system using this type of microprocessor has become difficult. The reason for this is that this type of microprocessor outputs its execution states only when a memory access is missed in the cache memory and therefore, it is not possible to monitor the current execution state of the program by tracing the memory access.
In the case of debugging a system having this type of microprocessor, a so called debugger is used. When only the executing process of a program is to be traced by the debugger, all memory accesses required by the microprocessor can be outputted to an external of the microprocessor by making the cache memory inactive (this state is called "cache off"). However, this tracing under the "cache off" state has a different executing time from a real operation of the microprocessor performed using the cache memory, and therefore, this debugging method is not as effective for a system required to have a real-time operation. In order to debug a real time operation while using the debugger, a break function is used to obtain the real time result. This break function causes the microprocessor to execute a branch instruction at an arbitrary address of a program. The other hand, a program for outputting an internal condition of the microprocessor and an intermediate result of the program execution which the user wishes to know are prepared, so that the user can observe whether or not an expected processing has been executed.
One typical conventional break function is disclosed in Japanese Patent Application Laid-open Publication No. Hei 03-078038 (JP-A-3-078038) entitled "In-Circuit Emulator".
Now, this typical conventional break function will be described with reference to FIG. 1.
In FIG. 1, a debugger is constituted by elements located at the right side of line 600, is coupled to a microprocessor 601 designates having a cache memory (not shown) therein and coupled to a first data bus 108 and an address bus 111.
More specifically, Reference Numeral 602 shows a user memory provided in a user system and coupled to a second data bus 109. Reference Numeral 603 indicates a front-end monitor which is provided on the user memory 602 and which is required to operated the debugger (it is necessary for the user of the debugger to prepare this memory region for a debugger). Reference Numeral 604 denotes a background monitor provided in the debugger, independently of the user memory 602, and coupled to the address bus 111 and the second data bus 109. Reference Numeral 605 symbolizes a memory space switching circuit, which is coupled to the address bus 111, the second data bus 109 and the user memory 602, and which operates to separate the background monitor 604 from the user space under the control of the front-end monitor. Reference Numeral 104 designates a breakpoint register coupled to the second data bus 109 configured to be set with a breaking point by a user. Reference Numeral 106 shows a comparator having a first input coupled to the address bus 111 and a second input coupled to the breakpoint register 104, for generating a coincidence signal or TRPRQ signal 114 when a coincidence is detected. Reference Numeral 103 denotes an instruction substituting circuit which substitutes a branch instruction for an instruction which should be read to the microprocessor, when the TRPRQ signal 114 is activated. This type of branch instruction is called a "break instruction".
When a user operates the break function, before execution of a debugging, the user sets the breakpoint register 104 with an address at which an interruption is caused. The comparator 106 compares an content of the address bus 111 outputted from the microprocessor 601 with a content of the breakpoint register 104. If they are concordant with each other, the TRPRQ signal 114 is activated. If the TRPRQ signal 114 becomes active, the instruction substituting circuit 103 substitutes the break instruction for the instruction which the microprocessor should read at that time.
Successive operations performed after this will be explained with reference to FIG. 2, which shows a timing chart of the operation of the conventional debugger.
Now, it is assumed that the breakpoint is set in an address "a", so that a break instruction is read into the microprocessor when the address "a" is accessed.
If the break instruction is executed by the microprocessor 601, the operation is branched to the head of a front-end monitor program. As mentioned above, the front-end monitor 603 is in a space which is reserved in the user memory 602 and which is utilized by the debugger. In accordance with the front-end monitor program, the front-end monitor 603 operates to turn the cache memory "off" and to analyze the primary factor of the break. If the front-end monitor 603 concludes a certain necessity of trap as the result of the primary factor analysis, it instructs the memory space switching circuit 605 to prevent, in succeeding accesses, the user memory is from being accessed, but allows the background monitor 604 to be accessed. As mentioned above, the background monitor 604 exists in the memory space on the debugger, independently of the user space. In the background monitor, a dump processing of an internal register is performed, and finally, a RETI (return-from-interrupt) instruction is executed so that the microprocessor 601 executes an original instruction before it was interrupted by the break instruction (called a "resumption instruction"). The resumption instruction is executed under the "cache off" condition. After the resumption instruction has been executed, the cache is returned back to the "cache on" condition. These controls of the cache are performed by the front-end monitor 603.
The prior art debugger as mentioned above needs the front-end monitor to perform the break function in the microprocessor including the cache memory therein. The following are the reasons why the front-end monitor 603 is necessary.
(1) The front-end monitor is required to switch the operation to the background monitor 604. PA1 (2) The front-end monitor is required to switch over to the "cache off" condition in accordance with a monitor program. Generally, the change to the "cache off" can be controlled in accordance with the monitor program by either the background monitor 109 or the front-end monitor 603. However, the foreground monitor (front-end monitor 603) and the background monitor are not distinguished from each other in the microprocessor. Therefore, if this processing is performed by the background monitor, there is the possibility that an instruction registered in the cache memory is hit during an execution in the user space 602. Thus, a malfunction occurs. On the other hand, if the processing in question is carried out by the foreground monitor, since it is in the user memory space, even if the cache memory is hit, no malfunction occurs. PA1 (3) There is no means for erasing the break instruction registered in the cache memory. Because of this, the resumption instruction after the break processing is executed under the "cache off" condition, so that the break instruction already registered in the cache memory is intentionally neglected. However, in the case that the address where the breakpoint is previously set, is accessed again, if the cache memory is hit, the breaking processing is repeated many times. As a result, the breaking point cannot be canceled until the end of the program. Therefore, it is necessary in the prior art for the front-end monitor 603 to judge the necessity of a break.
Because of the above mentioned reasons, the front-end monitor 603 has been used on the debugger in the prior art. The front-end monitor 603 uses the resources of the user system (for example, control signals for address bus of the user system, the user memory, etc.). This is disadvantageous in that a user's memory space (for examples addresses and contents of programs) is inevitably limited.
Further, in a case that the debugger itself utilizes the user system to debug a system under development, when a malfunction occurs in the user system, the monitor program itself does not properly function. The inherent function of the debugger itself cannot be exerted.
Furthermore, since as mentioned above the prior art debugger does not have the means for erasing the break instruction remaining in the cache memory, the front-end monitor 603 may operate unnecessarily to judge the necessity of the break instruction. Because of this, the ability to perform real time operation is lost in the user program execution.